Requirement gathering and analysis:
Business Analyst (BA) will get the requirement from the client and prepare a document called Business Requirement Document (BRD) or Software Requirements Specification (SRS) Document.

Design:
Then a document will be prepared called Design Specification Document, which will give details about how the front and back end could interact.

Development:
Then Developers will develop the software by the use of any coding language and they will do a test called Unit Testing.

Testing:
Once developer coded for the functionality of the software then they will move their code or build into testing environment. Once developer moved the code into testing phase, testers will test the applications as per the flow STLC (Software Testing Life Cycle).

Deployment:
Once a program has passed the testing phase, it is ready for deployment. Here the application will be deployed in the live environment. Typically, it happens at Non-Peak Hours.

Operation and Maintenance:
Here maintenance of software can include software upgrades, repairs and fixes of the software if it breaks.

Software Testing Life Cycle is a sequence of activities conducted to perform Software Testing. There are five phases of STLC:

• Requirement Analysis
• Test Planning
• Test Design
• Test execution
• Sign Off

Each of these five phases have a specific Entry and Exit criteria. Entry criteria is the prerequisite items need to start a phase and Exit criteria is the items that must be concluded when a phase is completed.

Requirement Analysis starts with BR Document and Design Specific Document. Here we need to go through the requirement in BR Document and understand the requirements. If we have any queries means we need to mark in a query log which will be clarified by Business Analyst (BA) in walkthrough session and need to get application access from the client. So here our scope will be finalized.

With the scope in requirement analysis, we will start the test planning. Here test lead will prepare Test Plan document with inscope and outscope which means what are all the areas we are going to cover in testing. Then types of testing with what tools we are going to test will be mentioned with explanation. Then expected date will be calculated for test case preparation, test case review, execution, etc. Then resource planning like how many testers needed will be mentioned in the document. So here Test Plan document is prepared.

With Test Plan document, we will start test design. Here we will prepare test case document for our requirements using Test scenario, Test cases, Test Data, Test Step Description, Expected Result, Actual Result and Status of the test cases. Once Test case is prepared, we need to get review from our peer or lead. Then we need to get approval from Business Analyst. For Automation testing, we will do skeleton scripting. So here Test Case Document is prepared.

Once developer provide the build to us after developing, using Test case document we will start with the execution. During execution if any defect found means, we will raise it and track it to closure. Once all test cases are pass, we will attach test results with the requirements. So here Test Results are generated.

Once test execution is completed, in Sign Off phase, our testing team manager will analyze the test results and draft a mail to Sign off for the application to release.

In Defect Management Tool, we need to click the create button and then select the issue as bug. Then we need to provide the defect name in summary and provide detailed information about the bug in description by mentioning, the bug is found in which environment, platform and browser. Then we will provide the steps to reproduce with expected, actual result and Test Data. Then we will provide the priority of the bug. Then we will attach the screenshots with the bug and link the bug with the story, so that we can track it easily. Then we will assign the bug to the developer and click create button. Then we will track the bug using bug life cycle.

Defect Life Cycle: When we found a defect for the first time, we will raise it as bug. Then we will assign it to the Developer. Then Developer will open the bug and verify whether it is valid or invalid bug. If it is a valid bug means, developer will fix it. Once developer fixed the bug, they will move it to testing team for retesting. After receiving the new build, we need to Retest the bug whether it is fixed or not. If the bug is fixed, then we need to verify and close the bug. If the bug is not fixed means, then we need to reopen the bug by assigning it back to the developer. Here developers also can reject the bugs by Duplicate – if the same bug was already raised by someone. Not a bug – if developers feel it’s not a genuine bug. Deferred – if developers feel it can be fixed later on upcoming sprint or releases (mostly low priority bugs).

• Smoke Testing: This testing is done to make sure if the build we received from the development team is testable or not. It is also called as Day 0 check. It helps not to waste the testing time to simply
• Regression Testing: This testing is done to make sure the existing functionalities of the application is not impacted whenever any new functionalities is added to the application.
• Sanity Testing: This testing is done during the release phase to check the main functionalities of the application without going deeper. Due to release time constraints, if regression testing can't be done to the build, in that case sanity testing does that part by checking main functionalities.
• Retesting: Once the developer fixes the bug, we need to test again whether the bug we raised is fixed or not in the latest build.
• Positive Testing: It is to determine what system supposed to do. It helps to check whether the application is justifying the requirements or not.
• Negative Testing: It is to determine what system not supposed to do. It helps to find the defects from the software.
• Formal Testing: It is a process where the testers test the application by having pre-planned procedures and proper documentation.
• Informal Testing: It is a process where the testers test the application without having any pre-planned procedures and proper documentation.
• User Acceptance Testing: UAT Testing is the final stage of software testing where real users test the application to make sure it meets their needs and works as expected before going live.
• Exploratory Testing: When testers explore the application without predefined test cases, using their creativity to find issues. It’s like testing the app by just interacting with it freely, looking for bugs as they go.

Equivalence Class Partitioning: Consider that we have to select an age between 18-56, Here the Valid inputs are 18-56 and the invalid inputs are <=17 and =>57. Here we have one valid and two invalid test cases.

Decision Table Technique: Login validation - Allow user to login only when both the username and password is correct. Condition1: Enter valid username and valid password and Click Login. Action1: Display home page and execute. Condition2: Enter invalid username and valid password and Click Login. Action2: Display Error message as invalid username.

State Transition Technique: Login with invalid username and password three times keeps the account page blocked until change password.

Boundary Value Analysis: If we want to enter an amount between 100 to 1000. Here we check based on boundaries for 100, we take 99,101 for valid and for 1000, we take 999,1001 as invalid.

Positive cases:

• Verify pen writes clearly on standard paper.
• Verify ink color matches the label on the pen.
• Verify cap fits securely on the pen and does not fall off.
• Verify pen writes immediately after uncapping without needing to shake.
• Verify there is no ink leakage from any part of the pen.
• Verify pen continues to write smoothly after writing several pages.
• Verify pen cap opens and closes easily without damage.
• Verify pen is easy to hold and provides good control while writing.
• Verify pen is lightweight and comfortable to use for extended writing.
• Verify pen writes smoothly on different types of paper (e.g., rough, glossy, recycled).

Negative cases:

• Verify pen does not write when ink is dried up or empty
• Verify pen does not write when held upside down for a long time.
• Verify pen does not write after being left uncapped for 24 hours.
• Verify pen leaks when stored in a hot environment.
• Verify pen tip breaks when excessive pressure is applied.
• Verify pen does not write smoothly on glossy or waxy paper.
• Verify pen body cracks when dropped from a height.
• Verify pen is uncomfortable to hold for long writing sessions.
• Verify pen emits a strong or unpleasant odor.
• Verify pen cannot be used after being frozen.

Positive cases:

• Verify mobile phone powers on when the power button is pressed.
• Verify mobile phone unlocks with the correct PIN/password/pattern.
• Verify battery charges when connected to a charger.
• Verify phone screen auto-rotates when turned.
• Verify camera opens and captures photos and videos.
• Verify Bluetooth connects to other Bluetooth-enabled devices.
• Verify mobile phone locks automatically after the set time.
• Verify volume buttons adjust sound levels properly.
• Verify mobile phone restarts correctly when rebooted.
• Verify mobile phone can be put in silent, vibration, and airplane modes.

Negative cases:

• Verify mobile phone does not unlock with an incorrect PIN/password/pattern.
• Verify mobile phone does not charge with a damaged charging cable.
• Verify mobile phone does not connect to Wi-Fi with an incorrect password.
• Verify mobile phone does not overheat during normal usage.
• Verify mobile phone does not restart automatically without user input.
• Verify mobile phone does not play sound when in silent mode.
• Verify mobile phone does not connect to Bluetooth device out of range.
• Verify mobile phone does not respond to power button if battery is dead.
• Verify screen does not rotate when auto-rotate is disabled.
• Verify mobile phone does not perform actions when screen is locked.

• Verify successful login with valid username and password.
• Verify login fails with invalid password.
• Verify login fails with invalid username.
• Verify login fails when both username and password are empty.
• Verify 'Remember Me' retains user credentials after logout.
• Verify ‘Forgot Password’ link redirects to reset page.
• Verify login button is disabled when username and password fields are empty.
• Verify username field does not accept more than 50 characters.
• Verify password field masks input characters.
• Verify user cannot log in after 5 consecutive failed attempts (if lockout is implemented).

• High Priority & Low Severity: The "Submit" button on a form is misaligned but still works perfectly when clicked. This is a high priority issue because it affects the user interface but the functionality is not affected, making it low severity.
• Low Priority & High Severity: An application crashes when trying to submit a form, but this feature is rarely used by users. This is low priority because it affects a feature that very few users interact with. However, the high severity is because the website crashes, which is a critical issue if it occurs.
• High Priority & High Severity: A payment gateway an application is down, and users can't complete their purchases. This is high priority because the issue directly impacts users to make purchases. It's also high severity because the system's core functionality is completely broken, leading to a severe impact.
• Low Priority & Low Severity: A minor typo in the "About Us" section of a website that doesn't affect the overall meaning. This issue is low priority because it’s just a typo in non-critical content. It’s also low severity because it doesn't cause any functional issues, so it’s not a major concern.

• Verification makes sure the product is being built correctly according to specifications. It’s done during the development phase.
• Validation makes sure the product meets the user's needs and requirements. It’s done during the testing phase.